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Abstract 


This document describes a set of mappings which will enable inter 
working between systems operating the ISO/IEC 10021 - CCITT (now ITU) 
X.400 Recommendations on Message Handling Systems, and systems 
running the Mail-11 (also known as DECnet mail or VMSmail) protocol. 
The specifications are valid both within DECnet Phase IV and 
DECnet/OSI addressing and routing scheme. 


The complete scenario of X.400 / MIME / Mail-11 is also considered, 
in order to cover the possible complex cases arising in multiple 
gateway translations. 


This document covers mainly the X.400 O/R address to/from Mail-11 
address mapping and the RFC822 to/from Mail-11 ones; other mappings 
are based on MIXER specifications. Bodypart mappings are not 
specified in this document: MIXER and MIME-MHS specifications can be 
applied to map bodyparts between X.400, MIME and Mail-11, too. In 
fact MIME encoding can be used without modifications within Mail-11 
text bodyparts. 


This document obsoletes RFC 1405, which was a combined effort of 


TERENA Working Group on Messaging, and the IETF X.400 Ops Working 
Group. This update was prepared by IETF MIXER working group. 
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Chapter 1 - Introduction 
Vita Xi 400 


The standard referred shortly into this document as "X.400" relates 
to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series 
Recommendations covering the Message Oriented Text Interchange 
Service (MOTIS). This document covers the Inter Personal Messaging 
System (IPMS) only. 


1.2. Mail-11 


Mail-11, also known as DECnet mail and often improperly referred as 
VMSmail, is the proprietary protocol implemented by Digital Equipment 
Corporation (DEC) to establish a real-time text messaging system 
among systems implementing the DECnet Phase IV and DECnet/OSI (CLNS) 
networking protocols. 


1.3. RFC822 / MIME 


RFC822 was defined as a standard for personal messaging systems 
within the DARPA Internet and is now diffused on top of many 
different message transfer protocols, like SMTP, UUCP, BITNET, JNT 
Grey Book, CSnet. MIME specifications allows transport of non-textual 
information into RFC822 messages. Their mapping with X.400 is fully 
described in MIXER and MIME-MHS. In this document we will consider 
their relations with Mail-11, too. 


1.4. The user community 


The community using MIME or X.400 messaging system is currently 
growing in the whole world, but there is still a number of very large 
communities using Mail-11 based messaging systems willing to 
communicate easily with X.400 based Message Handling Systems and with 
MIME based systems. Among these large DECnet based networks we can 
include the High Energy Physics network (HEPnet) and the Space 
Physics Analysis Network (SPAN). 


Many other local communities actively use internally Mail-11 mailing 
protocols. As any other "non standard" mail protocol, using non 
standard mapping techniques between Mail-11 and standard mail systems 
can produce unpredictable results. 


For these reasons a set of rules covering conversion between Mail-11 
and X.400 or MIME is described in this document. 
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This document also covers the case of Mail-11 systems implementing 
the "foreign mail protocol" allowing Mail-11 to interface other mail 
systems, including RFC822 based system. 


Chapter 2 - Message Elements 
2.1. Service Elements 


Mail-11 protocol offers a very restricted set of elements composing a 
Inter Personal Message (IPM), whereas X.400 and RFC822/MIME 
specifications support a complex and large amount of service 
elements. Considering the case where a message is relayed between 
two X.400 MHS or MIME Message Transport System (MTS) via a Mail-11 
messaging system this could result in a nearly complete loss of 
information. 


To minimise the inconvenience, any of the X.400 or MIME service 
elements which do not map directly into Mail-11 equivalent ones 
accordingly to this specification, will be included into Mail-11 text 
body parts as an additional RFC822-like header; this additional 
header will be inserted between the Mail-11 P2 headers (From:, To:, 
CC:, Subj:) and the other Mail-11 bodyparts. In particular, X.400 
elements will also be at first converted into textual representation 
before insertion. 


An example, where a multimedia message has been encoded into mail-11 
after having crossed also a MIME-MHS (MIXER conformant) gateway: 


From:  smtp*"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 
To: ALLOCCHIO 

CC: smtpS"netman@MailFLOW.dante.net" 

Subj: enjoy this nice picture! 


X400-Originator: root@sun3.SURFnet.nl 

X400-Recipients: Allocchio@elettra.ts.it, netman@MailFLOW.dante.net 
Sender: Erik Newmann <root@SURFnet.nl> 

Organisation: SURFnet bv 

Mime-Version: 1.0 

Content-Type: multipart/mixed; boundary="----- = _ aaaaaa0" 
Content-ID: <21223.78342785@SURFnet.nl> 


sesssss =_aaaaaa0 
Content-Type: text/plain; charset="us-ascii" 
Content-ID: <21223.78342785@SURFnet.nl> 


look... you never saw this one!! 
I just include the picture in the next bodypart 
and I hope you get it fine. 
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regards, 
Erik (continues...) 


iaia =_aaaaaa0 (continued...) 
Content-Type: image/gif 

Content-ID: <21223.78342785@SURFnet.nl> 
Content-Description: a nice snapshot! 
Content-Transfer-Encoding: base64 


RAV8372FAASD83D721NSHDHD3ASDFJKHWEHKJHCBASDFA829CA8SDB29B132RBAKDFA 
9KSJ2KJAAOSDFNAL20DDKFALJ20AJDLFB239B9SC9B29BA9BDFADSDF03998ASDFASD 


Pinin ne, = _aaaaaa0 


We need, in fact, to consider also the case when a message originates 
from a network implementing RFC822/MIME protocols and is relayed via 
Mail-11 to an X.400 MHS, or vice versa. 


Whenever any X.400 element not covered in this specification needs to 
be converted into textual representation (to be included into a 
Mail-11 RFC822-like header or text bodypart) we will apply the rules 
specified in MIXER (X.400 to RFC822/MIME sections). 


Vice versa, MIXER specification (RFC822/MIME to X.400 sections) also 
gives the correct rules to convert from textual representations 
contained into Mail-11 RFC822-like header or bodyparts into X.400 
elements. 


On the other hand, RFC822/MIME headers not covered by this 
specification are included "as they are’ into Mail-11 RFC822-like 
header and bodyparts. The way back from Mail-11 to RFC822/MIME 
structure becomes thus straightforward. 


The above methods assures maximum transparency and minimal or null 
loss of information also when Mail-11 is involved. 


Allocchio Experimental [Page 4] 


REC 2162 MaXIM-11 January 1998 


2.2. Mail-11 service elements to X.400 service elements. 


All envelope (P1) and header (P2) Mail-11 service elements are 
supported in the conversion to X.400. Note that Mail-11 P1 is solely 
composed by P1-11.From and P1-11.To, and any other Mail-11 element 
belongs to Mail-11 P2: 


P1-11.From 
maps to P1.Originator 


- P1-11.To 
maps to Pl.Primary Recipient 


= P2=11L, Erome” 
usually maps to P2.0riginator (see section 2.6) 


=P2=11xFT61% 
maps to P2.Primary Recipient 


= (R251i RC 
maps to P2.Copy Recipient 


- P2-11.Date 
maps to P2.Submission Time Stamp 


- P2-11.'’Subj:’ 
maps to P2.Subject 


Any eventual RFC822-like text header in Mail-11 body part will be 
interpreted as specified into MIXER. 


2.3. X.400 service elements to Mail-11 service elements 


The following X.400 service elements are supported directly into 
Mail-11 conversion: 


P1.Originator 
maps to Pl-11.’From:’ 


Pl.Primary Recipients 
maps to P1l-11.’To:’ 


P2.Originator 
usually maps to P2-11.’From:’ (see section 2.6) 


- P2.Primary Recipients 
maps to P2-11.’To:’ 
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- P2.Copy Recipients 
Maps. ‘to P21)... Cey" 


- P2.Submission Time Stamp 
maps to P2-11.Date 


- P2.Subject 
maps to P2-11.’Subj:’ 


The following X.400 service element is partially supported into 
Mail-11 conversion: 


- P2.Blind Copy Recipient 
to ensure the required privacy, when a message contains 


a 


BCC address, the following actions occurs: 

a new message is created, containing the body parts; 

a new envelope is added to the new message, containing 
the originator and the BCC recipient addresses only; 

a note is added to the message informing the BCC 
recipient about the fact that the message was a BCC; 
the new message is delivered separately; 

a note is added to the message delivered to TO and CC 
recipients informing them about the fact that there 
were some BCC recipients, too. 


Any other X.400 service element support is done accordingly to MIXER 
including the mapped element into the RFC822-like header into Mail-11 
body part. 


2.4. Mail-11 service elements to RFC822/MIME service elements. 


All envelope 
supported in 


Allocchio 


Pl-11. 


Plata, 


P2-L1 


P2=11% 


BIL 


(P1) and header (P2) Mail-11 service elements are 
the conversion to RFC822/MIME: 


From 
maps to 822-MTS.Originator 


To 
maps to 822-MTS.Primary Recipient 


"From:” 
usually maps to 822.’From:’ (see section 2.6) 


STO. 


maps to 822.’To:’ 


CCC” 


maps to 822.’Cc:’ 
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- P2-11.Date 
maps to 822.’Date:’ 


- P2-11.’Subj:’ 
maps to 822.’Subject:’ 


Any eventual RFC822-like text header in Mail-11 body part will be 
re-inserted into RFC822/MIME message ’as it is’. 


2.5. RFC822/MIME service elements to Mail-11 service elements 


The following RFC822 service elements are supported directly into 
Mail-11 conversion: 


822-MTS.Originator 
maps to P1-11.From 


- 822-MTS.Primary Recipients 
maps to Pl-11.To 


= 822.’From:’ 
usually maps to P2-11.’From:’ (see section 2.5) 


= B22 TO 
maps to P2-11.’To:’ 


BZ COR 
maps to P2-11.’CC:’ 


- 822.’Date:’ 
maps to P2-11.Date 


- 822.’Subject:’ 
maps to P2-11.’Subj:’ 
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The following RFC822 service element is partially supported into 
Mail-11 conversion: 


= 8220" BESS! 
to ensure the required privacy, when a message contains 
a BCC address, the following actions occurs: 

- a new message is created, containing the body parts; 
- a new envelope is added to the new message, containing 
the originator and the BCC recipient addresses only; 

- a note is added to the message informing the BCC 
recipient about the fact that the message was a BCC; 

- the new message is delivered separately; 

- a note is added to the message delivered to TO and CC 
recipients informing them about the fact that there 
were some BCC recipients, too. 


Any other RFC822/MIME service element support is done simply 
including the element ’as it is’ into the RFC822-like header and into 
a Mail-11 body part. 


2.6. Rules to define the Mail-11 P2-11.’From:’ element 


Mail-11 User Agents (usually VMSmail) uses the P2-11.’From:’ element 
as destination in case the REPLY command is issued, ignoring any 
other specification like ’Sender:’ ’Reply-To:’ ’Return-Path:’ etc. 
Also a number of automatic responders uses this field only to address 
their messages. 


Is it thus essential to insert into this field the correct 
information, i.e. the correct address where, according to X.400 or 
RFC822 rules the REPLY command or any automatically generated message 
should go. 


The rules specified in RFC822, section 4.4.4 should be used as a 
selection criterion to define the content of this field. 


In particular, in case the P2-11.’From:’ element is not generated 
from the P2.Originator (X.400) or from the 822.’From:’ (RFC822), it 
is essential to preserve into a ’/From:’ record of the RFC822-like 
header the original information contained into the P2.Originator or 
822.’From:’ fields. 
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Vice versa, when converting from Mail-11 into X.400 or RFC822/MIME 
the information contained into the ’From:’ field of the RFC822-like 
header (if present) will supersede the one contained into the Mail-11 
P2-11.’From:’. An example: 


From: smtp*"Admin@SURFnet.nl" "Erik" 18-OCT-1994 13:55:00.49 
To: ALLOCCHIO 

CC: smtp%"netman@MailFLOW.dante.net" 

Subj: enjoy this nice picture! 


From: Erik Newmann <root@SURFnet.nl> 
Reply-To: Admin@SURFnet.nl 
Organisation: SURFnet bv 

Message-Id: <21235.25442281@SURFnet.nl> 


when converting back into RFC822 the header will be: 


From: Erik Newmann <root@SURFnet.nl> 
Reply-To: Admin@SUREFnet.nl 

To: Allocchio@elettra.ts.it 

Cc: netman@MailFLOW.dante.net 

Subject: enjoy this nice picture! 
Organisation: SURFnet bv 

Message-Id: <21235.25442281@SURFnet.nl> 


The described method, although violating canonical conversion 
principles, assures the maximum functionality to the users, and 
provides consistency in case of multiple conversions for a single 
message. 


Chapter 3 - Basic Mappings 


The basic mappings indicated in MIXER and its updates should be fully 
used. 


A special consideration must be used for encoding RFC822 addresses 
containing quotes ’"’ into Mail-11. In fact Mail-11 addresses cannot 
contain that special character, as it is reserved to delimit "quoted 
strings" themselves, as when using the Mail-11 foreign mail protocol. 
An example: 


"John Poe"@Mixergw.local.ca.us (RFC822) 


cannot be included in a Mail-11 foreign mail protocol address ‘as 
is’, due to the quotes in the LHS section. Quotes must thus be 
encoded. MIXER specifies exactly how to encode quotes and other 
characters when translating RFC822 addresses into X.400. Mail-11 
addresses are not limited to printablestring, as for X.400, but a 
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subset of the MIXER encoding can be used for the quotes character, 
and, as a direct consequence, for open and closed round brackets ’ (’ 
and ’)": 
smtp%"(q) John Poe(q)@Mixergw.local.ca.us" 

Chapter 4 - Addressing - Mail-11 / X.400 

4.1. Mail-11 addressing 
Mail-11 addressing can vary from a very simple case up to complex 
ones, if there are other Mail-11 to "something-else" gateways 
involved. In any case a Mail-11 address is an ASCII string composed 
of different elements. 

4.2. X.400 addressing 
On the other hand, An X.400 O/R address is a collection of 
attributes, which can anyway be presented as an IA5 textual 
representation as defined in RFC1685 and CCITT F.401, Annex B. 

4.3. Mail-11 address components 
Let us start defining the different parts composing a Mail-11 
address. Mail-11 addresses syntax is slightly different between Phase 
IV and DECnet/OSI cases: 
- Phase IV: we consider a Mail-11 address as composed by 3 parts: 


[route] [node::] local-part 


where ’route’ and ‘’node’ are optional and only ’local-part’ is 
compulsory. 


— DECnet/OSI: we consider a Mail-11 address as composed by 3 parts: 
[net:] [node-clns::] local-part 


where "net and ’node-clns’ are optional and only ’local-part’ is 
compulsory. 


Here comes a formal definition of these elements 
node = *(ALPHA/DIGIT) / *DIGIT / *DIGIT "." *DIGIT 
route = *(node "::") 


subdomain = * (ALPHA/DIGIT) 
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node-clns = *("." subdomain) 


net = * (ALPHA/DIGIT) 


local-part = username / nickname / for-protocol 
username = * (ALPHA/DIGIT) 

nickname = <printablestring - <" " and HTAB>> 
for-protocol = (f-pref f-sep <">f-address<">) 


f-pref = * (ALPHA/DIGIT) 
f-sep = "gm / Ween 
f-address = printablestring / RFC822-address / X400-text-address 


X400-text-address = <textual representation of an X.400 O/R addr> 


Please note that in x400-text-address both the ";" notation and the 
"/" notation are equivalent and allowed (see examples in different 
sect.) 


Some examples (Phase IV): 


route node local-part 
USER47 
MYNODE: :BETTY 
BOSTON: :CLUS02::GOOFY1::MARY34 
INS"M.P.Tracy@Dicdum.cc.edu" 
UCLA13: :MVAX93: :MRGATE: :"MBOX1: :MBX34: :MYC3: : BOB" 
MIAMI2::George.Rosenthal 
CCUBVX: :VS3100: :Jnet%"IAB3425@IBAX23L" 
MRGATE: :"C=xx::A=bbb: :P=ppp: :S=Joe" 
MAINVX: : INS"path1!path2!user%dom" 
GWX400::gw%"C=xx;ADMD=aaa; PRMD=ppp; S=Lee; " 
GX409A: :x400%"/C=xx/A=aaa/P=ppp/S=Lee" 
smtp%s"postmast@nodeb.bitnet" 
MICKEY: :PRFGAT: :profs¢"NANCY@IBMB" 
edu%"HU427BDSCSUNIB@abc.acme.edu" 
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Some examples (DECnet/OSI): 


net node local-part 
USER47 
.IT.MYDOM1.MYNODE: : BETTY 
OMNI: .US.GOV.LB.GOOFY1: :MARY34 
INS"M.P.Tracy@Dicdum.cc.edu" 
NET1:.SALES.ADM.MVAX93: :MRGATE: :"MBOX1: :MBX34: :MYC3::BOB" 
.FR.LYON.MIAMI2::George.Rosenthal 
-AU.ABXY2W.VS3100: :Jnet%"IAB3425@IBAX23L" 
MRGATE: :"C=xx: :A=bbb: :P=ppp: :S=Joe" 
INT: .GB.3LABV56.MAINV: :INS"path1!path2!user%sdom" 
GWX400: :gw%"C=xx; ADMD=aaa; PRMD=ppp; S=Lee; " 
smtps"postmast@nodeb.bitnet" 
OMNI:.DE.TEST.V1.GWY32::GX409A::x400%"/C=xx/A=aaa/P=ppp/S=Lee" 


Note that also in DECnet/OSI there can be Phase IV like node names, 
the so called "Phase IV compatibility node names", but no ‘route’ 
term is allowed in front of them. In case the address consists of a 
DECnet/OSI ’net’ and/or ’node’ specification, plus an old Phase IV 
node address (like the last one in above examples) we consider the 
old Phese IV node name (GX409A) as ’local-part’. 


Chapter 5 - Mapping - Mail-11 / X.400 
5.1. Mapping scheme 


DECnet phase IV address field is somehow a ’flat land’ with some 
obliged routes to reach some hidden areas. Thus a truly hierarchical 
mapping scheme using mapping rules as suitable for RFC822 is not the 
appropriate solution. A fixed set of encoding rules using DDAS 
support is defined in order to define the mapping. 


DECnet/OSI address field is, on the other hand, hyerarchical, 
implementing a real domain style organization, resembling very 
closely the RFC822 domain addresses. However also in DECnet/OSI 
networks the old Phase IV flat addresing schema remains valid, 
expecially for the so called ’Phase IV short aliases’. For this 
reason, and to keep mapping as simple as possible, the same set of 
fixed rules usind DDAs encoding will be used both for Phase IV and 
DECnet/OSI addresses. 
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Another important aspect of the problem is the coexistence in DECnet 
phase IV of many disjoint networks, using the same DECnet address 
space, i.e., common X.400 and/or RFC822 mailing system acting as glue 
to connect different isolated Mail-11 islands. In DECnet/OSI this 
aspect is more canonically approached, introducing the concept of 
‘net’, a unique name identifying the single internally fully 
interconnected DECnet network sharing the same DECnet/OSI name space. 


To identify uniquely each DECnet Phase IV network we will thus extend 
the concept of DECnet/OSI ‘net’ also to this case. We define as ’net’ 
in Phase IV a unique ASCII string identifying the DECnet network we 
are connected to. If the Phase IV network is already migrating and 
thus interconnected to DECnet/OSI areas, the ’net’ identifier already 
used in the DECnet/OSI areas is automatically extended to the whole 
DECnet community. 


If the network still uses Phase IV protocols only, a ‘net’ identifier 
must be chosen. In this case the ‘net’ element will identify the 
DECnet community being served, but it could also differ from the 
actual official network name. It is reccommended that the same ‘net’ 
identifier will be adopted unmodified when the eventual migration to 
DECnet/OSI will take place within that DECnet community. 


Aliases are allowed for the ‘net’ identifier. Some well known 
identifiers and aliases: 


net = ’OMNI’ the High Energy Physics & Space Physics 
DECnet network; 
aliases: 
net = ’HEPnet’ alias for ’OMNI’ 
net = ’SPAN’ alias for ’OMNI’ 


The need of labelling each DECnet network with its name comes also 
from the requirement to implement the ’intelligent’ gateway, i.e., 
the gateway which is able to understand its ability to connect 
directly to the specified DECnet network, even if the O/R address 
specify a path to a different gateway. A more detailed discussion of 
the problem is in 5.3 and 5.5. 
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A registry of ’net’ attributes to insure uniqueness of names must be 
established: this registry is the same one created for migration to 
DECnet /OSI. A simple table coupling ’net’ and the gateway address is 
also used, in a syntax similar to the ’gatel’ and ’gate2’ tables used 
in MIXER. An example: 


OMNI #O0USCosine-gw.O$@.PRMDSinfn.ADMDSgarr.CSIT# 
OMNI#OSESRIN1.PRMDSesa.ADMDSMaster400.CSit# 
HEPnet #OUSCosine-gw.O$@.PRMDSinfn.ADMDSgarr.CSIT# 
HEPnet#O$ESRIN1.PRMD$esa.ADMD$Master400.C$it# 
SPAN#0USCosine-gw.O$@.PRMDSinfn.ADMDSgarr.CSIT# 
SPAN#OSESRIN1.PRMDSesa.ADMDSMaster400.CSit# 


Ambiguous left entries are allowed. Gateway implementations could 
simply choose among one of the specified gateways, or try them all in 
cyclic order to obtain better performances. 


Note that aliases are established using this gate table, too: simply 
add equivalent entries into the table, like the ’HEPnet’ and ’SPAN’ 
entries. Aliases, however, must be used only to enable users to use 
commonly used names, but any gateway implementing this specification 
must generate addresses with official ’net’ names, only (’OMNI’ for 
the above table). 


The Mail-11 gateways table, however, just constitutes the list of the 
the appropriate MIXER address translation) RFC822 world. Any other 
gateway implementing this specification (and the related ones) should 
use its local name as first choice for the Mail-11 ’net’ it can 
reach, and use the official Mail-11 gateway table to reach only the 
non connected ones. This list of Mail-11 gateway entries is supposed 
to contain the list of ’net’ tags and their aliases; as this list is 
usually small, currently we do not take into account distribution 
mechanisms for this information different from a static table. 


In order to keep the mapping rules very simple, avoiding the need to 
analyse Mail-11 addresses to distinguish the ’route’, ’node’, and 
Attributes (DDAS) needed to cover the mapping problem. 

5.2. Mail-11 --> X.400 


We define the following Domain Defined Attributes to map a Mail-11 
address: 


DD.Dnet 
DD.Mail-11 
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We thus define the Mail-11 Phase IV mapping rule: 
route: :node::localpart 
maps into 


C=xx; ADMD=yyy; PRMD=zzz; 0=000; OU=uuu; DD.Dnet=net; 
DD.Mail-—11=route: :node::localpart; 


Meanwhile we define the mapping rule for Mail-11 DECnet/OSI: 


net :node-clns::localpart 
maps into 


C=xx; ADMD=yyy; PRMD=zzz; 0=000; OU=uuu; DD.Dnet=net; 
DD.Mail-11=node-clns::localpart; 


with: 
xx = country code of the gateway performing the conversion 
yyy = Admd of the gateway performing the conversion 
zzz = Prmd of the gateway performing the conversion 


ooo = Organisation of the gateway performing the conversion 
uuu = Org. Unit(s) of the gateway performing the conversion 
net = name of the DECnet network (e.g., OMNI, HEPnet, SPAN,...) 


(’z2zz’',’ooo’,’uuu’ being used or dropped appropriately in order to 
identify uniquely within the X.400 MHS the gateway performing the 
conversion). 


The following defaults also apply: 


if ’node’ (or ’node-clns’) is missing and we are mapping the Mail-11 
originator (From) then ‘node’ (or ’node-clns’) defaults to the DECnet 
node name of the gateway (gwnode) ; 


if ’node’ (or ’node-clns’) is missing and we are mapping the Mail-11 
recipient (To, Cc) then ‘node’ (or ‘node-clns’) defaults to the 
DECnet node name of the ‘From’ address. 


if ’net’ is missing, then it defaults to a value defined locally by 
the gateway: if the gateway is connected to one DECnet network only, 
then ‘net’ will be the name of this unique network; if the gateway is 
connected to more than one DECnet network, then the gateway will 
establish a ’first choice’ DECnet network, and ’net’ will default to 
this value. 
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The ’node’ syntax (DECnet/OSI or Phase IV) depends on the DECnet 
protocol implemented and on the value of a system parameter (usually 
the MAIL$SYSTEM_FLAGS one) on the gateway host. 


In case ’local-part’ contains ’x400-text-address’ see also section 
624.537 


In case ’local-part’ contains ’RFC822-address’ see also section 
6.4.4. 


5.2.1. Examples 
Let us suppose that: 


— the DECnet network name (net) is ’OMNI’; 

- the DECnet node name of the gateway (gwnode) is ’.IT.DM.X4TDEC’ 
alias ’X4TDEC’ in Phase IV; 

- the Country Code of the gateway is ’IT’ and its ADMD is ’garr’ 
(and these two fields are enough to identify uniquely the gateway 
within the X.400 MHS). 


USER47 
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=.1T.DM.X4TDEC: :USER47; 


MYNODE: : BETTY 
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=MYNODE::BETTY; 


BOSTON: :GOOFY1: :MARY34 
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=BOSTON: :GOOFY1: :MARY34; 


.DE.UNI-BN.PHYS.NODE18: :MARY34 
C=it; ADMD=garr; DD.Dnet=OMNI; 
DD.Mail-11=.DE.UNI-BN.PHYS.NODE18::MARY34; 


UCLA13: :MVAX93: :MRGATE: : "MBOX1: :MBX34:MYC3: : BOB" 
C=it; ADMD=garr; DD.Dnet=OMNI; 
DD.Mail-11=UCLA13::MVAX93::MRGATE: : (q)MBOX1: :MBX34: :MYC3: : BOB (q) 


ENET: .US.CENTRAL.MIAMI2: :George.Rosenthal 
C=it; ADMD=garr; DD.Dnet=ENET; 
DD.Mail-11=.US.CENTRAL.MIAMI2::George.Rosenthal; 


MRGATE::"C=xx::A=bbb::P=ppp::S=Joe" 
C=it; ADMD=garr; DD.Dnet=OMNI; 
DD.Mail-11=X4TDEC: :MRGATE:: (q) C=xx: :A=bbb: :P=ppp: :S=Joe (q) 
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MAINVX: :InS"path1!path2!user%dom" 
C=it; ADMD=garr; DD.Dnet=OMNI; 
DD.Mail-11=MAINVX::In(p) (q) pathl1 (b) path2 (b) user (p) dom(q) 
5.3. X.400 encoding of Mail-11 --> Mail-11 


In order to assure path reversibility in case of multiple Mail- 
11/X.400 gateway crossing we must distinguish two cases: 


- DD.Dnet=net is known to the gateway as one of the DECnet networks 
it is connected to. In this case the mapping is trivial: 


C=xx; ADMD=yyy; PRMD=zzz; 0=000; OU=uuu; DD.Dnet=net; 
DD.Mail-—11=route: :node::localpart; 


(see sect. 5.2 for explication of '’xx’,’yyy’,'’zzz’,'’oo0o’,’uuu’,’net’) 
maps into 

route: :node::localpart 
and for DECnet/OSI addresses 


C=xx; ADMD=yyy; PRMD=zzz; 0=000; OU=uuu; DD.Dnet=net; 
DD.Mail-11=node-clns::localpart; 


maps into 
net :node-clns::localpart 
- DD.Dnet=net is NOT known to the gateway as one of the DECnet 
networks it is connected to. In this case the mapping rule 


described into section 5.4 apply: 


C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 
DD.Mail-—11=route: :node::localpart; 


maps into 


gwnode: :gwe"C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 
DD.Mail—-11=route: :node::localpart;" 
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Again for DECnet/OSI addresses: 


C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 
DD.Mail-11=node-clns::localpart; 


maps into 


gwnode: :gwe"C=xx; ADMD=yyy; PRMD=www; DD.Dnet=net; 
DD.Mail-11=node-clns::localpart;" 


5.3.1. Examples 
Let us suppose that: 


- the DECnet network name 
- the DECnet node name of 

alias ’X4TDEC’ in Phase 
- the Country Code of the 


(and these two fields are 
within the X.400 MHS). 


(net) is ’OMNI’; 

the gateway (gwnode) is ’.IT.DM.X4TDEC’; 
IV; 

gateway is ’IT’ and its ADMD is ’garr’; 


enough to identify uniquely the gateway 


C=it; ADMD=garr; DD.Dnet=OMNI; 


DD.Mail-11=X4TDEC: :MRGATE 


:: (q) C=ab: :A=dsa: :P=qwty: :OU=mie: :S=Cly (q) 


MRGATE: :"C=ab: :A=dsa: :P=qwty: :OU=mie::S=Cly" 


C=it; ADMD=garr; DD.Dnet=EASYNET; DD.Mail-11=ROMO1::CARLO; 
X4TDEC: :gwS"C=it; ADMD=garr;DD.Dnet=EASYNET; 


DD.Mail-11=ROM01: : CARLO 


e" 
1 


(in the above example ’/EASYNET’ is supposed to be not connected to 
our gateway located on .IT.DM.X4TDEC DECnet node). 


5.4. X.400 --> Mail-11 


The mapping of an X.400 O/R address into Mail-11 is done encoding the 


various attributes into the 


X400-text-address as defined in chapter 4 


of MIXER, and including this as ’f-address’. A ’f-pref’ and a the 
DECnet node name of the gateway. 
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Thus 
x400-text-address 
will be encoded like 
gwnode : :gw%"x400-text-address" 
having spaces dividing attributes as optional. 
5.4.1. Example 
Let us suppose that: 


- the DECnet node name of the gateway (gwnode) is ’.IT.DM.X4TDEC’ 
alias ’X4TDEC’ in Phase IV, and ‘net’ is ’OMNI’ 


Thus 
C=gb; ADMD=G400; PRMD=AC.UK; O=ucl; S=Clay; 

will be encoded like 

X4TDEC: :gw%"/C=gb/A=G400/P=AC.UK/O=ucl/S=Clay" 

or its equivalent with the ";" notation and DECnet/OSI ‘node’ 

OMNI: .IT.DM.X4TDEC: :gw%"C=gb; ADMD=G400; PRMD=AC . UK; O=ucl; S=Clay;" 

5.5. Mail-11 encoding of X.400 --> X.400 

It can happen that Mail-11 is used to relay messages between X.400 
systems; this will mean multiple X.400/Mail-11 gateway crossing and 
we will encounter Mail-11 addresses containing embedded X.400 


informations. In order to assure path reversibility we must then 
distinguish two cases: 
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- the embedded X.400 address belongs to a domain whose naming and 
routing rules are known to the global X.400 MHS. In this case the 
mapping is trivial: 

route::gwnode::gw%"x400-text-address" 
or (for DECnet/OST) 
net :gwnode: :gw%"x400-text-address" 


maps into 


x400-text-address 


‘route’ and ’gwnode’ are mapped into X.400 Trace service elements. 


- the encoded X.400 domain does not belong to the global X.400 name 
space. In this case the mapping rule described into section 5.2 


apply: 
route::gwnode::gw%"x400-text-address" 
maps into 


C=xx; ADMD=yyy; DD.Dnet=net; 
DD.Mail-11=route: :gwnode: :gw (p) (q) x400-text—address (q); 


and (for DECnet/OSI) 
net: gwnode: :gw%"x400-text-address" 
maps into 


C=xx; ADMD=yyy; DD.Dnet=net; 
DD.Mail-11=gwnode::gw(p) (q)x400-text-address (q); 


The latter case is deprecated and must be regarded as a possible 
temporary solution only, while waiting to include into the global 
X.400 MHS also this domain. 
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5.5.1. Examples 
Let us suppose that: 


— the DECnet network name (net) is ’OMNI’; 

- the DECnet node name of the gateway (gwnode) is ’.IT.DM.X4TDEC’ 
alias ’X4TDEC’ in Phase IV; 

- the Country Code of the gateway is ’IT’ and its ADMD is ’garr’; 
(and these two fields are enough to identify uniquely the 
gateway within the X.400 MHS). 


X4TDEC::gw%"C=fr;ADMD=atlas;PRMD=ifip;0=poly; S=Moreau; " 
C=fr; ADMD=atlas; PRMD=ifip; O=poly; S=Moreau; 


X4TDEC: :gwS"C=zz;ADMD= ;PRMD=Botwa; O=Miner; S=Chiuaw;" 
C=it; ADMD=garr; DD.Dnet=OMNI; 
DD.Mail-11=X4TDEC::gw(p) (q) C=zz;ADMD= ; 
PRMD=Botwa; O=Miner; S=Chiuaw; (q) 


(in the above example C=zz is unknown to the global X.400 MHS) 
Chapter 6 - Mapping - Mail-11 / RFC822 
6.1 Introduction 


The implementation of a Mail-11 - RFC822 gateway was faced by many 
software developers independently, and was included in many mail 
products which were running on both VMS and UNIX systems. As there 
was not a unique standard mapping way, the implementations resulted 
into a number of possible variant methods to map a Mail-11 address 
into an RFC822 one. Some of these products became then largely 
widespread, starting to create a number of de facto mapping methods. 


In this chapter some sort of standardisation of the mapping problem 
is considered, trying to be compatible with the existing installed 
software. We must also remind that, in some cases, only simple Mail- 
11 addresses could be mapped into RFC822, having complex ones 
producing all sort of quite strange results. In case DECnet/OSI 
Mail-11 addresses are involved we must also notice that only one 
mapping method can be used from/to RFC822 addresses. 
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On the other hand, the mapping of an RFC822 address in Mail-11 was 
quite straightforward, resulting in a common definition which uses 
"Mail-11 foreign mail protocol" to design an RFC822 address: 

[ [node::][node::]...]prot%"rfc-822-address" 
or 

[node::][node::]...]prot::"rfc-822-address" 
or again for DECnet/OSI addresses 

[net :][node-clns::]prot%"rfc-822-address" 
or 

[net :][node-clns::]prot::"rfc-822-addres" 

6.2 De facto implementations 

A considerable number of de-facto implementations of Mail-11/RFC822 
gateways is existing. As said in the introduction, the mapping of 
RFC822 addresses in Mail-11 is accomplished using the foreign mail 


protocol syntax and is thus unique. 


On the other hand, Mail-11 addresses are encoded in RFC822 syntax in 
various ways. Here are the most common ones: 


"node: :user"@gateway-address 
userSnode@gateway-—address 
user@node.decnet.domains 
user%Snode.dnet@gateway-address 


cao» 


Let’s have a quick look to these different choices. 


a - This form simply encloses as quoted Left Hand Side string the 
original Mail-11 address into the RFC822 address of the 
Mail-11/RFC822 gateway. This method is fully conformant with 
RFC822 syntax, and the Mail-11 address is left untouched; thus 
no encoding rules need to applied to it. This method applies also 
easily to DECnet/OSI Mail-11 addresses. 


b - As one will immediately notice, this form has nothing in it 
indicating the address is a Mail-11 one; this makes the encoding 
indistinguishable from a similar encoding of RSCS (BITnet) 
addresses used by some IBM VM Mailer systems. It should thus be 
deprecated. 
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c - In this case a sort of ‘reserved word’ (DECnet) embedded into 
the address itself identifies the presence of a Mail-11 original 
address preceding it. The decoding is possible, dropping 
‘domains’ and extracting ’user’ and ’node’ parts. However complex 
Mail-11 addresses cannot be mapped properly in this syntax, and 
there is no specific rule for adding the ’domains’ part of the 
address. 


d- In this case again there is a ’reserved word’ (dnet) which make 
possible the identification of the original Mail-11 address; 
'gateway-address’ points to the Mail-11/RFC822 gateway and ’node’ 
and ’user’ information can be easily drawn from the address. 
However complex Mail-11 addresses cannot be embedded easily into 
this syntax. 


Note the only methods a) can be successfully used for DECnet/OSI 
Mail-11 addresses, while the other cases are already too complex to 
encode in a unique way such addresses in RFC822. 
6.3 Recommended mappings 
From the examples seen in the previous paragraphs we can derive a 
canonical form for representing the mapping between Mail-11 and 
RFC822. 
6.3.1 RFC822 mapped in Mail-11 
The mapping of an RFC822 address in Mail-11 is straightforward, using 
the "Mail-11 foreign mail protocol" syntax. The two possible variants 
for Phase IV are: 
[ [node::][node::]...]prot%"rfc-822-address" 
or 
[node::] [node::]...]prot::"rfc-822-address" 
The equivalent two possible variants for DECnet/OSI are: 
[net :][node-clns::]prot%"rfc-822-address" 


or 


[net:] [node-clns::]prot::"rfc-822-address" 
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6.3.2 Mail-11 mapped in RFC822 


RFC822 foresee a canonical form for representing non-RFC822 
addresses: put the foreign address in local part (Left Hand Side, 
LHS) is a form as similar as possible to its original syntax. Thus 
the suggested mapping both for Phase IV and DECnet/OSI is: 


"Mail-11-address"@gateway-address 
This format assures also the return path via the appropriate gateway. 
6.3.3 Mail-11 (foreign mail protocol) mapped in RFC822 
A Mail-11 address containing a foreign mail protocol syntax can also 
contain the percent ’%’ character as a separator between the foreign 


protocol name and the actual address itself. In some cases the 
address part can also be an unquoted string. Some examples: 


deliver%Sswan 
myprot*root.owner 
listservsmy-private.list.Al 


If these addresses are encoded into an RFC822 address using the 
"natural" method described in 6.3.2, they will result in something 
which can be easily mismatched with an address using the percent hack 
in LHS for source routing. 


"myprot%root.owner"@lohost .mydom.edu (Mail-11 address) 
"LISTSERV%SIBMB.BITnet"@bitgate.anu.edu (% routing address) 


The percent hack is strongly deprecated, and thus should be avoided; 
the second address above shoud be expressed as: 


@bitgate.anu.edu:"LISTSERV@IBMB.BITnet" 


However, in order to assure maximum functionality and avoid problems, 
it is recommended to encode Mail-11 addresses containing the foreign 
protocol specification in RFC822 syntax using the DD.Mail-11 and 
DD.dnet qualifiers, i.e. 


"/DD.Mail-11=myprot%root.owner/DD.dnet=OMNI"@lohost.mydom.edu 


The DD.dnet defaults as indicated in the similar cases for the Mail- 
11 / X.400 mappings. This encoding method can, of course, also be 
used to map any other Mail-11 address in RFC822, and is the only one 
which enable to specify the network name (’OMNI’ in the above 
example) for DECnet Phase IV Mail-11 addresse. The method is fully 
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compatible with the results also produced by gateways following the 
MIXER specification for Mail-11 addresses encoded in X.400 and then 
translated into RFC822. 


Chapter 7 - Complex mapping - X.400 / Mail-11 / RFC822 
7.1. The protocol triangle 
The bilateral mappings described in chapters 5 and 6 must be extended 


in order to cover also the case in which also RFC822 addressing is 
involved, and the following triangular situation occurs: 


x.400 
/ \ 
/ \ 
/ \ 
Mail-11----RFC822 


The X.400 - RFC822 side is fully covered by MIXER, and the previous 
chapters in this document cover the Mail-11 - X.400 side and the 
Mail-11 - RFC822 one. 
7.2. RFC822 mapped in Mail-11 
The ’RFC822-address’ is usually included in ’local-part’ as 
route: :gwnode: :gws"rfc822-address" 
or the equivalent in DECnet/OSI: 
net: gwnode: :gw%"rfc822-address" 
An example in Phase IV 
NVXA23::SMTPGW::in%"M.T.Rose@CS.UCLA.edu" 
and another one in DECnet/OSI 
OMNI:.FR.INET.LABOL.SMTPGW::in%"M.T.Rose@CS.UCLA.edu" 
7.3. Mail-11 mapped in RFC822 
There are different styles in mapping a Mail-11 address in RFC822; 


let’s have a short summary of what was traditionally done in some 
implementations. 
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7.3.1 Mail-11 address encoded in "Left Hand Side" (LHS) of RFC822 


address, using "%" syntax or "::" syntax 
route: :node::localpart (Phase IV) 
maps to 


localpart Snode%troute@gw-domains 

or 
"route: :node::localpart"@gw-domains 
Again, let’s consider the DECnet/OSI case: 
net :node-clns::localpart (DECnet/OST) 

maps to 

"net :node-clns::localpart"@gw-domains 
(note that "%S" encoding does not exist for this case) 
where ’gw-domains’ identify uniquely the Mail-11 / RFC822 gateway. 


7.3.2 Mail-11 address maps partly to LHS and partly to ’domain’ part of 
RFC822 address 


node::localpart 
maps to 
localpart@node.gw-domains 


note that this kind of mapping does not exists with DECnet/OSI Mail- 
11 addresses. 


7.3.3 Mail-11 address is completely hidden by a mapping table 


In this case the resultant RFC822 address contains no trace at all of 
the original Mail-11 address. 
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7. 


7. 


7. 


4. 


4. 


4 


Multiple conversions 
Let us now examine briefly the possible situations which involve 
multiple conversions, having one protocol as a relay between the 
other two. This summary suggest some possible enhanced solutions to 
avoid heavy and unduly mappings, but the ’step by step’ approach, 
considering blindly one conversion as disjointed to the other, as 
described in the previous sections, can always be used. 
1. X.400 --> RFC822 --> Mail-11 
We apply the MIXER rules to the first step, obtaining an RFC822 
address which can be mapped in Mail-11 using the ’f-address’ field, 
as described in section 7.2. 
an example: 

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 
maps accordingly to MIXER to 

Jim.Clay@cs.UCL.AC.UK 
and finally becomes 

SMTPGW: :InS"Jim.Clay@cs.UCL.AC.UK" 
and finally becomes 

SMTPGW: :InS"Jim.Clay@cs.UCL.AC.UK" 
where ’SMTPGW’ is the DECnet Phase IV node name of the machine 
running the RFC822 to Mail-11 gateway. Again, in case the machine 
running the RFC822 to Mail-11 gateway is a DECnet/OSI one (like 
OMNI:.US.VA.CENTRL) we would get 

OMNI: .US.VA.CENTRL: :In%"Jim.Clay@cs.UCL.AC.UK" 
.2. Mail-11 --> RFC822 --> X.400 
Some of the possible mapping described in section 7.3 for Phase IV 


apply to the Mail-11 address, hiding completely its origin. The MIXER 
apply on the last step. 
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an example: 


RELAY: :MYNODE: : BETTY 


could map into RFC822 as 
BETTYSMYNODE@RELAY.dnet.gwl.it 
and accordingly to MIXER 
C=it; A=garr; P=doml; O=gwl; OU=RELAY; S=BETTY (p)MYNODE; 


where ’dnet.gwl.it’ is the domain of the machine running the Mail-11 
to RFC822 gateway. 


7.4.3. X.400 --> Mail-11 --> RFC822 


The X.400 address is stored into Mail-11 ’f-address’ element as 
described in sections 5.3 and 5.4; then if the Mail-11 to RFC822 
gateway is able to understand the presence of a ’x400-text-address’ 
nto the Mail-11 address, then it applies MIXER to it, and encodes 
header. Otherwise it applies the rules described in 7.3. 


an example: 

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 
will be encoded like 

X4TDEC: :gw%"/C=gb/A=Gold 400/P=AC.UK/0=UCL/0U=cs/G=Jim/S=Clay" 


If the Mail-11 to RFC822 gateway recognise the x400-text-address, 
then the address becomes, accordingly to MIXER 


Jim.Clay@cs.UCL.AC.UK 
and the following RFC822 header line is added 

Received: from X4TDEC with DECnet (Mail-11) on xx-xxx-xxxx. 
Otherwise one of the dumb rules could produce 

gw%"/C=gb/A=Gold 400/P=AC.UK/0=UCL/0U=cs/G=Jim/S=Clay"@XA4TDEC.doms 


The case with DECnet/OSI Mail-11 is conceptually identical. 
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7.4.4. RFC822 --> Mail-11 --> X.400 
The RFC822 address is encoded in Mail-11 f-address element as 
described in sect. 7.2; then if the Mail-11 to X.400 gateway is able 
to understand the presence of an ’RFC822-address’ into the Mail-11 
address, then it applies MIXER to it, and encodes ’route’ and applies 
the rules described in 5.2 and 5.5. 
an example: 

Jim.Clay@cs.UCL.AC.UK 

will be encoded like 


SMTPGW: :Ins"Jim.Clay@cs.UCL.AC.UK" 


If the Mail-11 to X.400 gateway recognise the RFC822-address, then 
the address becomes, accordingly to MIXER 


C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 


and a ’trace’ record is added into the X.400 P1 data, stating that a 
node named SMTPGW was crossed. 


Otherwise dumb rule produces 


C=it; ADMD=garr; DD.Dnet=HEP; 
DD .Mail-11=SMTPGW::In(p) (q) Jim.Clay (a) cs.UCL.AC.UK (q) 


Again, the case for DECnet/OSI Mail-11 addresses, is conceptually 
identical. 


7.4.5. RFC822 --> X.400 --> Mail.11 
We apply MIXER to the first conversion, obtaining an X.400 address. 


Then the rules described in sections 5.3 and 5.4 are used to store 
the X.400 address as ’x400-text-address’ into the Mail.-11. 
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an example: 

Jim.Clay@cs.UCL.AC.UK 
maps accordingly to MIXER to 

C=gb; ADMD=Gold 400; PRMD=AC.UK; O=UCL; OU=cs; G=Jim; S=Clay; 
and finally becomes 

SMTPGW: :gw%"/C=gb/A=Gold 400/P=AC.UK/0=UCL/0U=cs/G=Jim/S=Clay" 
where ’SMTPGW’ is the DECnet Phase IV node name of the machine 
running the X.400 to Mail-11 gateway. No differences also for 
DECnet/OSI Mail-11 addresses. 


7.4.6. Mail-11 --> X.400 --> RFC822 


The Mail-11 address is encoded as specified in sections 5.2 and 5.5; 
then MIXER is used to convert the address in RFC822. 


an example: 


RELAY: :MYNODE: : BETTY 


maps into X.400 as 
C=it; ADMD=garr; DD.Dnet=OMNI; DD.Mail-11=RELAY::MYNODE: : BETTY; 
and accordingly to MIXER 
"/C=it/A=garr/DD.Dnet=OMNI/DD.Mail-11=RELAY: :MYNODE: :BETTY"@gw2.it 


where ’gw2.it’ is the domain of the machine running the MIXER 
gateway. 


7.4. Conclusions 


A standard way of mapping Mail-11 addresses into RFC822 and vice 
versa is feasible. A suggestion is thus made to unify all existing 
and future implementations. It should be noted, however, that it 
could be impossible (in case of DECnet Phase IV) to specify in these 
mappings the name of the decnet community owning the encoded address, 
as it can be always done for X.400; thus the implementation of the 
‘intelligent’ gateway in this case could result impossible. 
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Chapter 8 - Notifications and Probes 


8.1. Overview 


Mail-11 is a real time protocol, i.e. connection is established 
directly to the destination node. This makes possible some level of 
services like verification of an address, and delivery confirmation. 


However, Mail-11 User Agents ususally do not support notification or 
probe services, whereas it is possible to deliver the result of a 
notification or a probe to Mail-11. In this section we will briefly 
describe the level of service which can be obtained on these services 
when Mail-11 is involved. 


8.2. Delivery of Notifications via Mail-11 


As described in the previous chapters, it is possible to transport 
also in Mail-11 with minimal loss of information complex information. 
This also includes Notifications. In fact Notifications in 
RFC822/MIME are encoded as MIME multipart messages: there are thus no 
problems in transporting these messages in Mail-11 as any other MIME 
message. Also X.400 Notifications can be transported and delivered 
via Mail-11: MIXER describes in fact how to convert them into MIME 
multipart messages, taking the problem back to the previous 
situation. 


Even when Mail-11 is just an intermediate step for a Notification 
message, this consideration just enable support for the service. 


8.3. Generation of Notifications and Probes from Mail-11 


Although Mail-11 does not support Notification or Probe, the service 
could also be supported at gateway level. In fact, due to real time 
nature of Mail-11 protocol, the gateway could be reasonably sure that 
delivery until the other end of the Mail-11 path was successful or 
unsuccessful (and try to verify the feasibility of a delivery in case 
a Probe as requested). However, Mail-11 could just be an intermediate 
relay service, vanishing the value of the information. 


Implementation of this kind of service at gateway level is thus 
questionable, and if done, should clearly state the situation where 
it was generated, and the "confidence level" it conveys. 


Security Considerations 


Security issues are not discussed in this memo. 
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